-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
src,http2: refactor + generalize http2 debugging #20987
Conversation
@@ -293,6 +293,13 @@ char ToLower(char c) { | |||
return c >= 'A' && c <= 'Z' ? c + ('a' - 'A') : c; | |||
} | |||
|
|||
std::string ToLower(const std::string& in) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Random unrelated questions - since we always build with an ICU - isn't this the sort of thing the ICU can do?
Also - is the loop below not a for(auto elm : in)
due to stylistic preference or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this the sort of thing the ICU can do?
No idea – doing it this way doesn’t cost us much though, though. @srl295 probably has a more helpful answer :)
Also - is the loop below not a
for(auto elm : in)
due to stylistic preference or something else?
We’d probably still want to set the characters in the output string directly rather than appending them one at a time, so we’d want to maintain an index for that. In those cases, yes, I prefer to use the explicit index for the input as well, even though we could do it without. :)
We have the |
@joyeecheung Nothing besides that this works slightly differently (currently category names correspond to |
@addaleax I am OK if the flag is dedicated for debugging output from the C++ side, as far as I know the environment variable is only honored in the JS land. But if we provide two mechanisms to achieve a similar purpose it would be rather confusing. |
src/env.cc
Outdated
break; | ||
// Use everything after the `,` as the list for the next iteration. | ||
debug_categories = | ||
debug_categories.substr(comma_pos); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this on a new line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the line was originally a bit longer. Fixed! :)
Implement utilities for easier debugging of Node.js core code, inspired by the HTTP/2 debugging code. Debugging is, however, implemented at runtime rather than at compile time, controlled through a new `NODE_DEBUG_NATIVE=categories` environment variable. The runtime overhead in the debugging-disabled case amounts to 1 well-cachable one-byte read per debug call.
@joyeecheung I’ve switched this to use |
The benchmark machine still doesn’t have |
Remove `--debug-http2` as a compile-time feature and make all debug statements available using `NODE_DEBUG_NATIVE=http2` at runtime. This probably makes the debugging-enabled case a bit slower due to additional string concatenations, but switching to a runtime-checking system makes debugging more flexible and can be applied more easily to other parts of the source code as well.
Benchmark results now look the way we want them to: Output in the fold
|
Can someone explain to me why the benchmark tool is confident that this improves performance by 1% in that benchmark? I don't see any changes that should do that but I don't know the http2 code well at all :) |
@benjamingr I’d expect it to be one of the 0.52 false positives we should expect. Running that benchmark more frequently shows no significant change:
|
@benjamingr It could be just fluctuations |
Ok, thanks for clarifying - maybe we should add a guide for how to read significance in the benchmark output. I've considered |
Implement utilities for easier debugging of Node.js core code, inspired by the HTTP/2 debugging code. Debugging is, however, implemented at runtime rather than at compile time, controlled through a new `NODE_DEBUG_NATIVE=categories` environment variable. The runtime overhead in the debugging-disabled case amounts to 1 well-cachable one-byte read per debug call. PR-URL: #20987 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Remove `--debug-http2` as a compile-time feature and make all debug statements available using `NODE_DEBUG_NATIVE=http2` at runtime. This probably makes the debugging-enabled case a bit slower due to additional string concatenations, but switching to a runtime-checking system makes debugging more flexible and can be applied more easily to other parts of the source code as well. PR-URL: #20987 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Implement utilities for easier debugging of Node.js core code, inspired by the HTTP/2 debugging code. Debugging is, however, implemented at runtime rather than at compile time, controlled through a new `NODE_DEBUG_NATIVE=categories` environment variable. The runtime overhead in the debugging-disabled case amounts to 1 well-cachable one-byte read per debug call. PR-URL: #20987 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Remove `--debug-http2` as a compile-time feature and make all debug statements available using `NODE_DEBUG_NATIVE=http2` at runtime. This probably makes the debugging-enabled case a bit slower due to additional string concatenations, but switching to a runtime-checking system makes debugging more flexible and can be applied more easily to other parts of the source code as well. PR-URL: #20987 Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com>
tl;dr: Instead of having to compile with
./configure --debug-http2
, get the same output withNODE_DEBUG_NATIVE=http2 node
at runtime, in a way that makes implementing similar debugging for other core modules easier.src: implement debug output utilities
Implement utilities for easier debugging of Node.js core code,
inspired by the HTTP/2 debugging code. Debugging is, however,
implemented at runtime rather than at compile time, controlled
through a new through a new
NODE_DEBUG_NATIVE=categories
environment variable.
The runtime overhead in the debugging-disabled case amounts to
1 well-cachable one-byte read per debug call.
http2: switch to new runtime-controlled debugging system
Remove
--debug-http2
as a compile-time feature andmake all debug statements available using
NODE_DEBUG_NATIVE=http2
at runtime.
This probably makes the debugging-enabled case a bit slower due to
additional string concatenations, but switching to a runtime-checking
system makes debugging more flexible and can be applied more easily
to other parts of the source code as well.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes